Add and update Timer requirements #75
Conversation
Add new Timers system requirements. Remove user story from the system requirements. Update description and titels of the existing requirements to fit better to the guidelines. Signed-off-by: Simon Hein <shein@baumer.com>
There was a problem hiding this comment.
I left a couple of comments and suggestions with the proposed changes.
There are only a couple of additional things I want to mention here>
- The function where the application can query the next expiry time in systicks is not covered.
- Do we need to specify how users can influence a timer's resolution (in ns/ms/whatever) ?
- For the thread syncing functionality do we need to allow for more than one thread that can synchronize with a given timer?
| <<< | ||
| USER_STORY: >>> | ||
| As a Zephyr RTOS user, I want to be able to track the passed real time in the OS with a dedicated hardware counter and interrupt. | ||
| The Zephyr RTOS shall provide a mechanism to define and initialize a timer at run time. |
There was a problem hiding this comment.
suggestion:
| The Zephyr RTOS shall provide a mechanism to define and initialize a timer at run time. | |
| The Zephyr RTOS shall provide a mechanism to define and initialize timers at run time. |
| TITLE: Call functions in interrupt context | ||
| TITLE: Timer definition at compile time | ||
| STATEMENT: >>> | ||
| The Zephyr RTOS shall provide a mechanism to define and initialize a timer at compile time. |
There was a problem hiding this comment.
suggestion:
| The Zephyr RTOS shall provide a mechanism to define and initialize a timer at compile time. | |
| The Zephyr RTOS shall provide a mechanism to define and initialize timers at compile time. |
There was a problem hiding this comment.
** nitpick **:
A technically more precise term is probably static initialization
| COMPONENT: Timers | ||
| TITLE: Timer status | ||
| STATEMENT: >>> | ||
| A Zephyr RTOS timer shall have a status which indicates the expiration of the timer. |
There was a problem hiding this comment.
suggestion:
| A Zephyr RTOS timer shall have a status which indicates the expiration of the timer. | |
| A Zephyr RTOS timer shall have a means to indicate whether the timer has already expired or not. |
I'd consider a status field a design spec and would leave it out of the RQT
There was a problem hiding this comment.
If it would speak about a status field here I would agree that it should be in the design, but in this case we only speak of a status a timer has if it is expired or not. Obviously that will most of the time end up in a design with a status filed 😄
| [REQUIREMENT] | ||
| UID: ZEP-SRS-4-3 | ||
| STATUS: Draft | ||
| TYPE: Non-Functional |
There was a problem hiding this comment.
question (non-blocking): Why is this non-functional?
There was a problem hiding this comment.
The status req is non functional because in first place this isn't good testable on it's own. And more detailed use of the status is specified in follow up regs.
| [REQUIREMENT] | ||
| UID: ZEP-SRS-4-4 | ||
| STATUS: Draft | ||
| TYPE: Non-Functional |
There was a problem hiding this comment.
question: Why is this non-functional?
There was a problem hiding this comment.
This is a simple copy paste error.
| STATUS: Draft | ||
| TYPE: Functional | ||
| COMPONENT: Timers | ||
| TITLE: Timer remaining expiration system tick time |
There was a problem hiding this comment.
suggestion:
| TITLE: Timer remaining expiration system tick time | |
| TITLE: Provide timer remaining expiration time in units of system ticks |
| STATUS: Draft | ||
| TYPE: Functional | ||
| COMPONENT: Timers | ||
| TITLE: Timer remaining expiration time |
There was a problem hiding this comment.
suggestion:
| TITLE: Timer remaining expiration time | |
| TITLE: Provide timer remaining expiration time in milliseconds |
| COMPONENT: Timers | ||
| TITLE: Timer remaining expiration time | ||
| STATEMENT: >>> | ||
| The Zephyr RTOS shall provide a mechanism to get the timer remaining until expiration time in milliseconds. |
There was a problem hiding this comment.
suggestion:
| The Zephyr RTOS shall provide a mechanism to get the timer remaining until expiration time in milliseconds. | |
| The Zephyr RTOS shall provide a mechanism to get the timer's remaining time until its next expiry in milliseconds. |
| [REQUIREMENT] | ||
| UID: ZEP-SRS-4-24 | ||
| STATUS: Draft | ||
| TYPE: Functional | ||
| COMPONENT: Timers | ||
| TITLE: Timer remaining expiration time | ||
| STATEMENT: >>> | ||
| The Zephyr RTOS shall provide a mechanism to get the timer remaining until expiration time in milliseconds. | ||
| <<< | ||
| RELATIONS: | ||
| - TYPE: Parent | ||
| VALUE: ZEP-SYRS-18 |
There was a problem hiding this comment.
question: Is this a duplicate of ZEP-SRS-4-23?
| [REQUIREMENT] | ||
| UID: ZEP-SRS-4-27 | ||
| STATUS: Draft | ||
| TYPE: Functional | ||
| COMPONENT: Timers | ||
| TITLE: Timer expire functions in interrupt context | ||
| STATEMENT: >>> | ||
| When the timer expiry function is defined, it shall be called in the interrupt context. |
There was a problem hiding this comment.
question: Is this really a requirement? To me this looks like a (natural) design rationale. This might not even be true for all architectures, ie. those that don't have a systick interrupt context like native_sim?
There was a problem hiding this comment.
In my opinion this is a requirement because if this wouldn't be here wouldn't the timer behave different on different architectures?
And do we really need to consider native sim, I don't think so because it is a simulation of a system and that usual behaves often different than a real architecture.
simhein
force-pushed
the
timers_req
branch
2 times, most recently
from
7861f70
to
bffab9a
Compare
Add new timers requirements on the software level Remove the user stories from the existing requirements. Remove obsolete requirements and rephrase existing ones. Signed-off-by: Simon Hein <shein@baumer.com>
Added.
I think that could be specified but i don't see it here for the feature timer. because it don't give options to influence a timers resolution.
Yes that is the way it is implemented as far as I see. |
Add new Timers system requirements.
Remove user story from the system requirements.
Add new software timers requirements.
Regenerate the software requirements UIDs